Rendering three-dimensional (3-D) graphics is an increasingly important application area for data processing units. This process is often aided with hardware implemented as integrated circuits.
Typically the 3-D graphics rendering process consists of several tasks. The rendering process begins from a collection of high level application data which describes the scene to be rendered as a collection of objects. These objects are then translated to a suitable co-ordinate space for the rendering system and their different attribute values are computed. The translated object information is then converted in a process called rasterization to a set of data values for each pixel (=picture element) covered by the object. As is well known, a rasterizer converts vector-based objects to pixels adapted for the rendering device, such as a display adapter. For simplicity, the invention will be described in connection with display devices but the invention is equally suited to hardcopy rendering devices (printers or film generators), although the requirement for speed is usually most intensive in real-time display systems.
The data values (or parameters) for each pixel can be broadly classified into two types. The first type of parameters indicate where and how a pixel should be rendered. These parameters comprise the co-ordinate (X, Y) and color (C) of the pixel. (The term "color" can also refer to shades of a single color, such as shades of gray). The second type of parameters contains information regarding to whether the pixel is to be drawn or suppressed. These parameters typically comprise a Z value which represents the pixel depth on the screen. The Z value is used in assembling the image correctly so that the images in front of the scene obstruct the objects behind them. (Within the context of this application, the terms "in front of" and "behind" should be interpreted as seen from the viewpoint of an imaginary viewer.) Also, one or more surface map or texture ("T") co-ordinate sets can be associated with each pixel. Other reasons for suppressing a pixel generated by the rasterizer can be e.g. implementing a transparency effect. This can be achieved by selecting pixels to be suppressed based on a raster pattern, or by implementing surfaces with holes in them by special texture attributes. The overall effect is that a significant portion of the pixels generated by the rasterizer will not be written to the screen memory.
The last step of the rendering process assembles and combines this data stream with the existing graphics state in order to create the final pixel values. The assembly process for a single pixel depends usually on several parameters, and also on the values of the pixels which have been previously rendered on the screen. The most typical dependency between pixels is the Z buffer ordering. If two pixels have the same co-ordinate values (X,Y) their Z values are compared, and the latter pixel is only drawn if its Z values designates it to be in front of the previous pixel. Thus the Z buffer comparison can cause a pixel to be suppressed (not drawn).
It is possible to handle the drawing operation by placing the units specified for each task in series, i.e. one after another. The problem with this architecture is that it is not very flexible. There are also limitations for the maximum complexity for the operations supported because each stage in the pipeline adds to the overall amount of the hardware.
Another problem with the previous architecture is that it requires separate dedicated memories for each portion, i.e. the Z, T and C buffers. Otherwise the multiplexing between the different tasks would cause an inefficient pattern of memory usage.
As all the operations are in the same pipeline it is difficult to delete pixels from the pipeline, for example after the Z comparison. In prior art systems, the pixels to be suppressed are tagged (marked) with a flag bit. During the Z and C write stages the pixel data tagged with such flag bits are not written to external memory.
It is possible to access the memory more effectively by performing each operation to a group of pixels in sequence and then advancing the processing to next operation stage. Because at any point of time, only one stage of the processing is being carried out, it is possible to use the same data path for implementing different stages. In this kind of architecture, the processing for a vector of pixels proceeds as follows: 1) the Z-values are read from the memory and compared; 2) each pixel is tagged with the comparison result; 3) the pixel's Z values are written to the Z buffer, but for the pixels which failed the Z comparison the actual write is suppressed. The same steps are repeated for the texture (T) and color (C) information. Again, the actual write operation is suppressed for the pixels which failed the Z comparison. It is notable that in existing implementations of this architecture, the pixels which failed the Z comparison are not removed from further processing which means that essentially all the processing concerning the texture, transparency etc. will be carried out for each pixel, regardless of whether or not the pixel will be drawn.